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REMARKS/ARGUMENTS 

Claims 1-24 are pending in this Application. 

Claims 6-8, 16-17, and 20-24 are currently amended. Applicants submit that 
support for the claim amendments can be found throughout the specification and the drawings. 

Claims 1-24 remain pending in the Application after entry of this Amendment. 
No new matter has been entered. 

In the Office Action, claims 1-24 stand rejected under 35 U.S. C. § 102(b) as being 
anticipated by non-patent literature entitled "SmarTeam™ FDA Compliance Technical Paper 
Functional Compliance With FDA Rule 21 CFR Part 11" (hereinafter "SmartTeam"). 

Objections to the Specification 

The Office Action objected to the Specification indicating that the reference to 
application numbers needs to be updated. Applicants have amended the Specification to include 
the reference to application numbers as requested in the Office Action, thus, Applicants 
respectfully request reconsideration and withdrawal of the objections to the Specification. 

Objections to the Claims 

The Office Action to claims 6-8, 16-17, and 23-24 due to informalities. 
Applicants have amended claims 6-8, 16-17, and 23-24 to correct the informalities as requested 
in the Office Action, thus, Applicants respectfully request reconsideration and withdrawal of the 
objections to claims 6-8, 16-17, and 23-24. 

Double Patenting 

The Office Action provisionally rejected claims 1 -24 of the present Application 
over claims 1-25 of co-pending Application No. 10/731,299 (hereinafter the '299 Application) 
using obviousness-type double patenting. The Office Actions alleges that claims 1-24 of the 
present Application are not patentably distinct from claims 1-25 of the '299 Application because 
claims 1-25 of the '299 Application anticipate the claims of the present Application. Applicants 
respectfully disagree. 
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Applicants respectfully submit that claims 1-24 of the present Application are 
patentably distinct from claim 1-25 of the '299 Application. Applicants respectfully submit that 
a person of ordinary skill in the art would not conclude that the invention recited in claim 1-24 of 
the present Application are anticipated by, or are obvious an variation of, the invention defined 
in claims 1-25 of the '299 Application. For example, claim 1 of the '299 Application recites a 
method of collecting an electronic signature for an electronic record stored in a database. As 
recited in claim 1 of the '299 Application, an electronic record is automatically created from data 
stored in a plurality of different database tables in response to the occurrence of a predetermined 
event. An instance of the electronic record is then stored in a common repository of electronic 
records that provides an audit trail that cannot be altered or disabled by users of the system. A 
rule associated with the electronic record is executed to determine whether an electronic 
signature is required to connote review and/or approval of the electronic record. If execution of 
the rule results in a determination that an electronic signature is required, the instance of the 
electronic record is marked as unsigned, and a request to collect the required electronic signature 
is initiated. Thus, claim 1 of the '299 Application recites a method of collecting an electronic 
signature to approve an electronic record . (Emphasis added). 

Applicants respectfully submit that this is substantially different from claims 1-24 
pending in the present Application. In contrast to claim 1 in the '299 Application, claim 1 of the 
present Application recites a method of intercepting a transaction instantiated by a database 
application to determine if an electronic signature is necessary to commit the transaction to the 
database. As recited in claim 1 of the present Application, the method comprises: 

in response to a triggering action generated by the database application, calling an 
application program interface to raise an event; 

initiating a workflow process that executes a rule to determine if an electronic 
signature is required to approve the transaction; and 

if execution of the rule results in a determination that an electronic signature is 
required for the transaction, instantiating a signature collection process. 
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Thus, claim 1 of the present Application recites a method for intercepting a 
transaction instantiated by a database application to determine if an electronic signature is 
necessary to commit the transaction to the database . (Emphasis added). 

For example, claim 1 of the '299 Application recites that a rule associated with 
the electronic record is executed to determine whether an electronic signature is required to 
connote review and/or approval of the electronic record . (Emphasis added). In contrast, claim 1 
of the present Application recites initiating a workflow process that executes a rule to determine 
if an electronic signature is required to approve the transaction . (Emphasis added). Thus, the 
electronic signatures are request for different types of objects: for an automatically created 
electronic record stored in a common repository in claim 1 of the '299 Application and for a 
transaction to be committed to a database in claim 1 of the present Application. 

Furthermore, claim 1 of the present Application recites calling an application 
program interface to raise an event in response to a triggering action generated by the database 
application. The above feature is missing from the claims of the '299 Application. Moreover, 
calling an application program interface to raise an event in response to a triggering action 
generated by the database application is quite different from claim 1 of the '299 Application that 
recites a method that creates an electronic record is automatically from data stored in a plurality 
of different database tables in response to the occurrence of a predetermined event . (Emphasis 
added). 

Applicants thus submit that claims 1-24 of the present Application are patentably 
distinct from claims 1-25 of the '299 Application. Applicants respectfully submit that a person 
of ordinary skill in the art would not conclude that the invention defined in claims 1-24 of the 
present Application is anticipated by, or would have been an obvious variation of, the invention 
defined in claims 1-25 of the '299 Application. Applicants thus submit that the double patenting 
rejection using co-pending Application No. 10/731,299 should be withdrawn. 

The Office Action further provisionally rejected claims 1-24 of the present 
Application over claims 1-26 of co-pending Application No. 10/731,655 (hereinafter the '655 
Application) using obviousness-type double patenting. The Office Actions alleges that claims 1- 
24 of the present Application are not patentably distinct from claims 1-26 of the '299 
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Application because claims 1-26 of the '655 Application anticipate the claims of the present 
Application. Applicants respectfully disagree. 

Applicants respectfully submit that claims 1-24 of the present Application are 
patentably distinct from claim 1-26 of the '655 Application. Applicants respectfully submit that 
a person of ordinary skill in the art would not conclude that the invention recited in claim 1-24 of 
the present Application are anticipated by, or are obvious an variation of, the invention defined 
in claims 1-26 of the '655 Application. For example, claim 1 of the '655 Application recites a 
committing a transaction to a database. As recited in claim 1 of the '655 Application, a database 
transaction is initiated. An electronic record is then created that includes transaction data from 
the database transaction. A rule associated with the electronic record is executed to determine 
whether an electronic signature is required to connote review of the electronic record. The 
electronic signature is then requested prior to committing the database transaction to the database 
based on a determination that an electronic signature is required. 

Applicants respectfully submit that this is substantially different from claims 1-24 
pending in the present Application. In contrast to claim 1 in the '655 Application, claim 1 of the 
present Application recites a method of intercepting a transaction instantiated by a database 
application to determine if an electronic signature is necessary to commit the transaction to the 
database. As recited in claim 1 of the present Application, the method comprises: 

in response to a triggering action generated by the database application, calling an 
application program interface to raise an event; 

initiating a workflow process that executes a rule to determine if an electronic 
signature is required to approve the transaction; and 

if execution of the rule results in a determination that an electronic signature is 
required for the transaction, instantiating a signature collection process. 

For example, claim 1 of the '655 Application recites that a rule associated with 
the electronic record is executed to determine whether an electronic signature is required to 
connote review of the electronic record . (Emphasis added). In contrast, as discussed above, 
claim 1 of the present Application recites initiating a workflow process that executes a rule to 
determine if an electronic signature is required to approve the transaction . (Emphasis added). 
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Thus, the electronic signatures are request for different types of objects: for an electronic record 
in claim 1 of the '655 Application and for a transaction to be committed to a database in claim 1 
of the present Application. 

Furthermore, claim 1 of the present Application recites calling an application 
program interface to raise an event in response to a triggering action generated by the database 
application. The above feature is missing from the claims of the '655 Application. 

Applicants thus submit that claims 1-24 of the present Application are patentably 
distinct from claims 1-26 of the '655 Application. Applicants respectfully submit that a person 
of ordinary skill in the art would not conclude that the invention defined in claims 1-24 of the 
present Application is anticipated by, or would have been an obvious variation of, the invention 
defined in claims 1-26 of the '655 Application. Applicants thus submit that the double patenting 
rejection using co-pending Application No. 10/731,655 should be withdrawn. 

Claim Rejections Under 35 U.S.C. S 101 

Applicants respectfully traverse the rejections to amended claims 20-24 and 
request reconsideration and withdrawal of the rejections under 35 U.S.C. § 101. 

Claim Rejections Under 35 U.S. C. § 102(b) 

Applicants respectfully traverse the rejections to claims 1-24 and request 
reconsideration and withdrawal of the rejections under 35 U.S.C. § 102(b) based on SmartTeam. 

Applicants respectfully note that to anticipate a pending claim, a prior art 
reference must provide, either expressly or inherently, each and every limitation of the pending 
claim. (M.P.E.P. § 2131). 

The Office Action alleges that SmartTeam teaches or suggests all of the claim 
limitations of claims 1-24. However, based on the arguments presented below, Applicants 
respectfully submit that SmartTeam fails to teach or suggest at least one of the claim limitation 
recited in each of claims 1-24. 
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Claim 1 

Claim 1 recites a method of intercepting a transaction instantiated by a data base 
application to determine if an electronic signature is necessary to commit the transaction to the 
database, the method comprising: 

in response to a triggering action generated by the database application, calling an 
application program interface to raise an event; 

initiating a workflow process that executes a rule to determine if an electronic 
signature is required to approve the transaction; and 

if execution of the rule results in a determination that an electronic signature is 
required for the transaction, instantiating a signature collection process. 

Applicants respectfully submit that SmartTcam fails to teach or suggest each and 
every claim limitation recited in claim 1 . 

The Office Action alleged that SmartTeam discloses the feature of "in response to 
a triggering action generated by the database application, calling an application program 
interface to raise an event" in section 2.2 of SmartTeam. Applicants respectfully disagree. 

SmartTeam merely presents a side-by-side comparison of FDA regulations to 
features of the SmartTeam software. In section 2.2, entitled "1 1 .50, 1 1 .70 Signature 
Manifestation and record linking," SmartTeam discloses that the SmartTeam software "tracks 
modification and life cycle operations," includes an approval function that "allows approving 
users through a workflow process. . .to electronically sign records," includes a server side 
mechanism to "silently integrate the signature into managed file," and allows an administrator to 
view the audit trail. SmartTeam further disclose that the user information on the records is saved 
"to document when a user created/uploaded or signed the records." 

However, SmartTeam fails to teach or suggest the feature recited in claim 1 of "in 
response to a triggering action generated by the database application, calling an application 
program interface to raise an event." The fact the SmartTeam software tracks modification and 
life cycle operations, allows users to electronically sign records, or includes a server side 
mechanism to integrate signatures into managed files does not disclose that an application 
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program interface is called as recited in claim 1 to raise an event in response to a triggering 
action generated by a database application. 

Further, claim 1 recites the feature of "initiating a workflow process that executes 
a rule to determine if an electronic signature is required to approve the transaction." SmartTeam 
merely indicates in section 2.2 that approving users can electronically sign records through a 
workflow process. However, simply electronically signing a record as in SmartTeam though a 
workflow process does not necessarily teach or suggest that a workflow process is initiated that 
executes a rule to determine if an electronic signature is required to approve a transaction as 
recited in claim 1 . SmartTeam fails to teach or suggest that a rules is executed to determine is an 
electronic signature is required to approve a transaction as recited in claim 1 . 

Additionally, claim 1 recites the feature of "if execution of the rule results in a 
determination that an electronic signature is required for the transaction, instantiating a signature 
collection process." Again, SmartTeam fails to teach or suggest that if execution of a rule results 
in a determination that an electronic signature is required for a transaction, a signature collection 
process is then instantiated. SmartTeam merely discloses that approving users may or may not 
through a workflow process electronically sign records. 

Moreover, the Office Action points to section 2.3 of SmartTeam in support of a 
prima facie case of anticipation. However, section 2.3 of SmartTeam merely indicates that two 
users cannot have the same user login, and that the SmartTeam software implementation team 
will comply with the certification requirement of rule 1 1 . 100. The Office Action fails to provide 
any discussion of how section 2.3 that compliance with the FDA rule that no two users have the 
same login and the fact that the software team anticipates compliance with the rule applies to the 
above -recited claim limitations. 

In light of the above, Applicants respectfully submit that SmartTeam fails to teach 
or suggest each and every claim limitation as recited in claim 1 . Thus, Applicants respectfully 
submit that claim 1 is allowable over the cited references. 
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Claim 2 

Claim 2 recites that an application program interface comprises an event name 
and an event id. The Office Action points to sections 2.2-2.3 of SmartTeam for allegedly 
disclosing the above recited feature. Applicants respectfully disagree. 

37 C.F.R. § 1.104(c)(2) states that "when a reference is complex or shows or 
describes inventions other than that claimed by the applicant, the particular part relied on must be 
designated as nearly as practicable." Applicants respectfully submit that merely pointing to 
sections 2.2-2.3 of SmartTeam fails to designate as nearly as practicable the alleged teachings in 
SmartTeam. However, Applicants respectfully submit that SmartTeam fails to teach or suggest 
an application program interface that comprises an event name and an event id as recited in claim 
1. 

For example, section 2.2 discloses that the software tracks the user performing the 
operation, the timestamp of the new record, and the type of operation. None of these, 
individually or in combination, teach or suggest that an application program interface comprises 
an event name and an event id as recited in claim 2. 

Furthermore, the Approval function in section 2.2 discloses that the full name of 
the signing user, the timestamp of the signature, and a meaning are kept on the record. None of 
these, either individually or in combination, teach or suggest an application program interface 
that comprises an event name and an event id as recited in claim 2. 

Moreover, the server side mechanism in section 2.2 merely integrates the 
signature into managed files. 

Additionally, the audit trail in section 2.2 includes the full name of the signer, the 
date and time, and the meaning of the operation. However, none of these, either individually or 
in combination, teach or suggest an application program interface that comprises an event name 
and an event id as recited in claim 2. 

The bottom box of section 2.2 indicates that the SmartTeam software saves the 
user information on the records. Merely saving information to provide an audit trail as in section 
2.2 of SmartTeam fails to teach or suggest an application program interface that comprises an 
event name and an event id as recited in claim 2. 
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In light of the above, Applicants respectfully submit that claim 2 is allowable over 
the cited references. 

Claim 2-24 

Applicants respectfully submit that independent claims 1 1 and 20 are allowable 
for at least a similar rationale as discussed above for the allowability of claim 1, and others. 
Applicants respectfully submit that dependent claims 2-10, 12-19, and 21-24 that depend directly 
and/or indirectly from the independent claims 1,11, and 20 respectively, are also allowable for at 
least a similar rationale as discussed above for the allowability of the independent claims. 
Applicants further respectfully submit that the dependent claims recite additional features that 
make the dependent claims allowable for additional reasons. 
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CONCLUSION 

In view of the foregoing, Applicants believe all claims now pending in this 
Application are in condition for allowance. The issuance of a formal Notice of Allowance at an 
early date is respectfully requested. 

If the Examiner believes a telephone conference would expedite prosecution of 
this application, please telephone the undersigned at 925-472-5000. 

Respectfully submitted, 



/Sean F. Parmenter/ 
Sean F. Parmenter 
Reg. No. 53,437 

TOWNSEND and TOWNSEND and CREW LLP 

Two Embarcadero Center, Eighth Floor 

San Francisco, California 941 1 1-3834 

Tel: 925-472-5000 

Fax: 415-576-0300 
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